Amazon FSx for NetApp ONTAPをSMBファイルサーバーとして動作させる時の運用項目を整理してみた
2024.11.12マネージドサービスを利用すると運用が楽になるらしいが、残る運用は何?
こんにちは、のんピ(@non____97)です。
皆さんはマネージドサービスを利用するにあたって、継続して自身が運用しなければならない運用に何があるのか気になったことはありますか? 私はあります。
「マネージドサービスを利用すると運用が楽になる!」とよく言われます。
では、「全ての運用がなくなるのか」というとそうではありません。残り続ける運用もあります。
今回は「Amazon FSx for NetApp ONTAP(以降FSxN)をSMBファイルサーバーとして動作させる場合」を例として、継続して行うべき運用を運用項目として整理してみます。
なお、FSxNを例に挙げますが、ほとんどAmazon FSx for Windows File Server(FSxW)でも同様の運用が必要になると考えます。FSxWを利用する際にも参考にしてください。
運用項目の種類の整理
運用項目は以下の3種類に大別されます。
- 業務運用
- 基盤運用
- 運用管理
業務運用は業務に関する運用を指します。
ファイルサーバーにおいては、ディレクトリを追加したり、SMBファイル共有を追加したりとファイルサーバーを利用するエンドユーザーの日常的な利用に関連する運用です。
基板運用はシステムが動作するインフラに関連する運用を指します。
ファイルサーバーにおいては、ファイルサーバーとして安定稼働を維持するために監視をしたり、バックアップをしたりすることが含まれます。
運用管理は運用に関わる人が守るべきルールや基準、体制の策定、トレーニングをすることを指します。
「運用を維持するための運用」と思うと良いかもしれません。
運用管理に関しては導入システムごとに一から個別で策定するよりかは、既存の運用管理方法に載せる形が多いと思います。
そのため、今回は業務運用と基盤運用について触れます。
業務運用
ディレクトリの管理
ファイルサーバー上ではユーザーが書き込む領域をディレクトリ単位で分割されています。
多くのファイルサーバーでは部署単位でディレクトリを切っていることが多いと考えます。
そのため、部署が新規に立ち上がったり、統廃合をしたりと、部署再編が発生した場合ばディレクトリを再編結果に伴い修正する必要があります。
部署のグループ内の再編であれば、その部署にディレクトリの修正を委任する形が良いと思いますが、全社的な対応の場合はファイルサーバーの管理部門が旗を振って管理、調整するのが良いでしょう。
具体的にディレクトリに対して行う運用は以下のとおりです。
- 作成
- リネーム
- 定期棚卸し
- 削除
- ACLの設定
- DACL
- SACL
SMBファイル共有管理
ユーザーがSMBファイルサーバー上のファイルにアクセスする際は、SMBファイル共有を設定する必要があります。
SMBファイル共有を設定するにはファイルサーバーの管理者権限が必要です。そのため、先述の「ディレクトリの管理」と同じく、ファイルサーバーの管理部門が行う運用作業となります。
SMBファイル共有が設定されているディレクトリは「共有ディレクトリ(共有フォルダ)」と呼ばれます。共有ディレクトリの注意点については以下記事で紹介しています。ユーザー部門と認識齟齬が生まれやすいところでもあるので、注意しましょう。
具体的にSMBファイル共有に対して行う運用は以下のとおりです。
- 作成
- リネーム
- 定期棚卸し
- 削除
- パスの変更
- ACLの設定
- オプションの設定
- 例
- 共有一覧への表示有無
- Snapshot領域へのアクセス有無
- 例
SMBクライアントユーザー管理
ファイルサーバーにアクセスするには、そのファイルサーバーへのアクセスする権限を持ったユーザーを用意する必要があります。
SMBファイルサーバーであれば、Active Directoryでユーザーを管理していることがほとんどでしょう。
Active Directoryの管理者がやるべきタスクだとは思いますが、以下のような運用が発生します。
- ADユーザーの管理
- 作成
- 定期棚卸し
- 削除
- パスワード再設定
- セキュリティグループの管理
- 作成
- 定期棚卸し
- 削除
- メンバーの追加/離脱
- 別セキュリティグループへの参加/離脱
※ GPOやOUの設計、管理は範囲が広すぎるので割愛
セッション管理
クライアントがフリーズした場合、利用者側からファイルのロックを開放できない状況になることがあります。
そのため、ファイルロックを開放するために、そのクライアントのセッションを削除する削除することがあります。詳細は以下記事をご覧ください。
ストレージクォータ管理
ユーザーごとや部門ごと、プロジェクトごとに割り当てたディレクトリに書き込みできる量を制限することがあります。
そのような制限をかけるストレージクォータの管理も運用の一つです。
FSxNにおけるストレージクォータについては以下記事をご覧ください。
具体的には以下のような運用が発生します。
- デフォルトクォータ/明示的クォータルール/派生クォータルールの作成
- デフォルトクォータ/明示的クォータ/派生クォータのリサイズ
- ソフトクォータ超過時のユーザーへの連絡
- 不要ファイル、一定期間アクセスの無いファイルの削除依頼
不要ファイル、一定期間アクセスの無いファイルの削除はNIASのような3rdパーティ製品を使用することで対応するのも良いでしょう。
基盤運用
監視
監視の内容は目的カットと監視対象カットの2種類で分類できます。
目的カットは目的によってカテゴライズするものです。監視手法は問いません。目的カットで分類するとは以下のような監視があります。
- 死活監視
- パフォーマンス監視
- バックアップ監視
- セキュリティ監視
- コスト監視
監視対象カットは監視する対象によってカテゴライズするものです。監視対象カットで分類すると以下のような監視があります。
- ICMP監視
- ポート監視
- サービス監視
- リソース監視
- イベント監視
- ログ監視
個人的には目的カットの方が好みです。監視は何かしらの目的を持って行うべきものだと考えます。監視対象カットだとついつい取り敢えず監視するだけになりがちと感じます。目的のない監視を行うと、アラート通知を受け取った後にどのような行動をすれば良いのか判断が付きにくいです。
以降、目的カットの監視項目について触れていきます。
死活監視
死活監視はシステム基盤やサービスが正常に稼働しているかどうかを確認することです。
死活監視と聞くとICMP監視やポート監視をイメージする方も多いと思います。ただし、死活監視 = ICMP監視やポート監視とは限りません。
例えば、AWS Healthによる監視も死活監視に含まれるでしょう。AWS Healthを用いることで対象AWSアカウントもしくはAWSサービスの異常を検知することが可能です。
AWS Organizationsで複数AWSアカウントを利用している場合は、AWS Health Dashboard の組織ビューを有効化すると運用が楽になります。
では、死活監視を完全にAWS Healthに寄せられるのかというと、そうではありません。個人的には「FSxNファイルシステム自体がダウンしてから発覚までのリードタイムを短くしたいのであれば、それに適した短い間隔のポート監視を実施する」必要があると考えます。
AWS Healthの通知はインデントが発生して即時ではなく数分〜数十分程度の遅延があります。そのため、短いリードタイムで利用者へのアナウンスなど何かしらの対応が求めらる場合はAWS Healthのみの監視は適しません。
「では、ポート監視だけで良いのか」というとそういう訳でもありません。
以下についても把握をしたいことがほとんどだと思います。こちらはポート監視だけでは判断できません。
- 何かしらの障害によりフェイルオーバーが発生したこと
- ノード単体だけでなく、FSxNファイルサーバー自体がダウンしたこと
前者について、Multi-AZにしている環境でことAZ障害やノード障害が発生した場合は60秒未満でフェイルオーバーするため、1分間隔のポート監視では検出できないことが想像されます。このシチュエーションについては別AZのノードに自動フェイルオーバーすることで業務継続はできているため、管理者がFSxNファイルシステムに対して直ちに実施しなければならない作業はない認識です。ただし、別AZにフェイルオーバーすることでレイテンシーが増加したりなど、関連する影響範囲を知るためにもフェイルオーバーの発生有無は把握しておきたいところです。
後者については、DRサイトを用意している場合に重要な判断材料です。
ポート監視による通知のみが上がって来たとしても、AWS Healthによる通知が上がってこなければ障害の規模などの全容が掴めず、DRサイトへのフェイルオーバーの判断が難しいと考えます。
また、外形監視も死活監視に含まれるように感じます。
「ポートが空いている や ICMP echo replay が返ってくる = ファイルサーバーの操作ができる」とは限りません。「SMBのバージョン制限をした結果、操作できなくなった」という事象はポート監視やICMP監視では気づくことができません。
クライアントがSMBファイルサーバーの利用ができているのか確認したいのであれば、定期的に指定のSMBファイル共有にアクセスして、テストファイルの作成/読み込み/削除ができるかどうかチェックすること良いかと思います。
ZabbixであればリモートコマンドでZabbix AgentをインストールしたSMBクライアントから上述の内容を実行するスクリプトを叩くと良いでしょう。
ファイルサーバーに接続してくるSMBクライアントが複数拠点に分散しているのであれば、各拠点のZabbix Agentをインストールしたノードから実行すると良いでしょう。単一拠点からのみの外形監視である場合、たまたまその拠点のネットワークとファイルサーバーとを接続するネットワークのみが不安定である場合も考えられます。
要するにその監視によって以下を整理している必要があります。
- その監視の通知が上がったということは、つまりどのような事象が発生していると判断できるのか
- その監視の通知が上がったことによって断定できないことは何か
- その事象に対して、どんなアクションを取ることができるのか
監視方法がカバーしている範囲を図で整理すると分かりやすいかと思います。
パフォーマンス監視
パフォーマンスが悪化していないか、悪化する予兆があるかを監視します。
主な確認観点は以下です。
| 監視項目 | FSxメトリクス | CloudWatchメトリクス名 | 通知を受け取った場合の対応例 |
|---|---|---|---|
| CPU使用率 | ファイルシステムメトリクス | CPUUtilization | スループットキャパシティの増加 |
| ネットワークスループット使用率 | ファイルシステムメトリクス | NetworkThroughputUtilization | スループットキャパシティの増加 |
| ディスクスループット使用率 | ファイルシステムメトリクス | FileServerDiskThroughputUtilization | スループットキャパシティの増加 |
| ディスクIOPS使用率 | ファイルシステムメトリクス | DiskIopsUtilization or FileServerDiskIopsUtilization | SSD IOPSまたはスループットキャパシティの増加 |
| SSD物理使用率 | 詳細なファイルシステムメトリクス | StorageCapacityUtilization | SSDのサイズ拡張 |
| ボリューム使用率 | ボリュームメトリクス | StorageCapacityUtilization | ボリュームのサイズ拡張 |
| inode使用率 | ボリュームメトリクス | FilesUsed / FilesCapacity * 100 | inodeの拡張 |
こちらは主に以下AWS公式ドキュメントの記載されている推奨事項をベースにまとめました。
「通知を受け取った場合の対応例」はあくまで一例です。高負荷の原因やストレージの圧迫の原因を調査したのち、その原因を取り除くことができない場合に実施の検討を行うものです。原因調査やその他に取りうる対応については以下記事でまとめているので併せてご覧ください。
FSxのコンソールから確認できるファイルシステムやボリュームのモニタリングは以下をご覧ください。
なお、レイテンシーやキャッシュヒット率については以下理由から監視項目からは除外しています。必要に応じて追加してください。
- 適正値を探るのが難しい
- アクセスパターンの影響が大きい
- 一部領域に対してではなく、全体的にレイテンシーやキャッシュヒット率が悪化している場合は、CPU使用率やディスクIOPSが高止まりしている可能性が高く、代替の監視手段がある
バックアップ監視
バックアップが正常に行われているかどうかを監視します。監視対象は以下の2つです。
- AWS Backupのバックアップジョブの実行結果
- SnapMirror relationshipのHealth
前者はCloudWatchメトリクスのNumberOfBackupJobsFailedに対してアラーム設定を行うことで監視できます。
後者についてはCloudWatchメトリクスは存在しません。そのため、以下のいずれかの対応が必要になります。
- NetAppのData infrastructure InsightでSnapMirror relationshipのHealthを監視する
- SnapMirror relationshipの状態をPutMetricDataするVPC Lambdaを定期実行し、そのカスタムメトリクスをベースにCloudWatchアラームを設定する
Data infrastructure Insight(以降DII)はNetAppが提供しているSaaSです。
以下のようにWebブラウザからSnapMirror relationshipのHealthを確認することが可能です。
抜粋 : ONTAP の基礎知識 - Data Infrastructure Insights
以下NetAppのTech ONTAP Blogsによるとnetapp_ontap.snapmirror.total_failed_countで監視できるようです。
詳細な監視設定手順は以下NetApp公式ドキュメントをご覧ください。
DIIはSaaSです。また、FSxNはDIIと連携する直接のインターフェイスを持っていません。そのためFSxNのデータをDIIへ連携するにあたってハブが必要になります。そのハブがAcquisition Unit (以降AU)です。
抜粋 : Observability for the Modern Datacenter with NetApp Cloud Insights - NetApp Community
AUはEC2インスタンスとして動作し、FSxN内の情報を取得します。収集される情報は以下ドキュメントにまとまっています。
EC2インスタンスの要件は以下をご覧ください。
EC2インスタンスの追加が必要になるため、以下のような考慮が必要になります。実現したいこととのバランスを考え導入可否を判断すると良いでしょう。
- EC2インスタンスのランニングコスト
- EC2インスタンスの運用コスト
- 資産棚卸
- ログ収集
- アクセス権限管理
- パッチ適用
- バックアップ
- 高可用性対応
- マルウェア対策
- DR対応
セキュリティ監視
不審なアクティビティがないかを監視します。
AWSレイヤーの脅威検知についてはGuardDutyの出番です。以下記事を参考にGuardDutyの通知を設定しておきましょう。
調査をする際にはAmazon Detectiveや弊社クラスメソッドメンバーズのインシデント自動調査機能を活用するのもオススメです。
ファイルサーバー上の不審なアクティビティの検出にはManageEngineのADAudit PlusやNetAppのDII Storage Workload Securityが候補です。
- ADAudit Plus
- DII Storage Workload Security (旧Cloud Insights Cloud Secure)
これらの3rdパーティ製品は別途ライセンスやソフトウェアを動作させるEC2インスタンスが必要になります。防ぎたい脅威とリスク、コストバランスを考え導入可否を判断すると良いでしょう。
コスト監視
コストが予算超過していないのか、コストに影響のある異常な使われ方をしていないのかを監視します。
以下記事を参考にAWS Cost Anomaly DetectionやAWS Budgetsのアラートを設定しましょう。
弊社のクラスメソッドメンバーズを利用されている方は、クラスメソッドメンバーズポータルから料金アラームを設定することも可能です。
抜粋 : [メンバーズ向け]既存のAWSアカウントにセキュアアカウント設定を一部導入してみた(リージョン限定、コスト優先) | DevelopersIO
監視項目のメンテナンス
監視は設定して終わりではありません。適宜メンテナンスを行う必要があります。
以下のような運用があります。
- 監視閾値の見直し
- 通知先メールアドレス、Slackチャンネルの見直し
- 監視対応手順の見直し
- 監視項目の追加/削除/棚卸し
リソース拡張
監視通知の内容の評価結果や、今後発生するであろうイベントから判断してリソースを拡張することがあります。
主な設定変更要素は以下のとおりです。
- スループットキャパシティの変更
- SSDサイズの拡張
- SSD IOPSの変更
- ボリュームサイズの変更
- inode数の変更
- ボリューム数の変更
パフォーマンスに関わる要素は以下AWS公式ドキュメントにまとまっています。
SSDサイズは拡張することは可能ですが、縮小することはできません。「SSD使用率が高い = SSDサイズの拡張を即座に行う」のではなく、以下のような対応をできないか検討しましょう。
- 不要ファイルの削除
- 不要Snapshotの削除
- Tiering Policyの変更
- キャパシティプールストレージにデータを流す
バックアップ/リストア
FSxNバックアップ方法は以下の3種類あります。
- AWS Backup
- Snapshot
- SnapMirror
Snapshotは厳密に言うとバックアップではないのですが、利用者からするとバックアップのように見えるので含めました。注意点は以下記事をご覧ください。
また、AWS BackupとSnapMirrorの使い分けは以下記事でまとめています。
運用としては以下のような対応が発生します
- バックアップ/Snapshot/SnapMirror relationship設定の追加
- 不要なバックアップ/Snapshot/SnapMirror relationship設定の削除
- 手動バックアップ/Snapshotの取得
- 不要なバックアップ/Snapshotの削除
- バックアップ/Snapshotを用いたボリューム全体リストア
- Snapshotを用いた個別ファイルのリストア
- Snapshotのロック
- 重大な変更を行う前に取得したSnapshotを誤って削除されることを防ぎたい場合などに実施
- AWS Backupのリーガルホールドの実施
- ランサムウェア被害など、トラブル調査が完了するまで既存のバックアップが保持期間に基づいて削除されることを防止する場合に実施
- バックアップ/リストア手順のメンテナンス
AWS Backupの場合はタグで簡単にバックアップ対象を選択することが可能です。一方、SnapshotやSnapMirrorはボリュームごとに都度設定する必要があります。
各リストア手順は以下記事をご覧ください。
Snapshotのロック方法は以下記事をご覧ください。
リーガルホールドについては以下記事をご覧ください。
DR
天災やAWSの大規模論理障害に対するDRが求められる場合は以下のような運用が発生します。
- DRサイトのメンテナンス
- プライマリサイトへ行った設定変更と同一の設定変更を実施
- 例
- SMBファイル共有の作成
- ボリュームの追加
- SMB暗号化の強制化
- DRサイトへのフェイルオーバー
- DRサイトからのフェイルバック
- 定期的なDR訓練
DRサイトとのフェイルオーバー/フェイルバックの具体的な手順は以下記事をご覧ください。
セキュリティ
セキュリティ向上のために以下のような運用が考えられます。
- ログ管理
- ユーザー管理
- IPS/IDS管理
- アンチマルウェアソフト連携管理
- FPolicy管理
- セキュリティグループのルール管理
- 個人情報スキャン
以降、それぞれの運用について簡単に触れていきます。
ログ管理
ログ取得の対象は以下のとおりです。
- CloudTrail
- VPC Flow Logs
- FSxN管理アクティビティの監査ログ
- NASアクセスの監査ログ
各ログに対する運用は以下のとおりです。
- ログ保持期間の調整
- ログロック期間の調整
- ログアクセス権限の調整
ONTAPユーザー管理
先述のSMBクライアントのユーザー管理だけでなく、ONTAPユーザーやロールの管理も必要です。
ONTAPユーザー、ONTAPロールに対する運用は以下のとおりです。
- ONTAPユーザーの管理
- 作成
- 削除
- 利用実績調査
- パスワードの更新
- ロック/ロック解除
- ONTAPロールの管理
- 作成
- 削除
- パスワードポリシーの設定
- ユーザーロックポリシーの設定
- ロック期間の設定
IPS/IDS管理
要件によってはAWS Network FirewallやTrend MicroのCloud One Network SecurityなどのIPS/IDSを導入することがあります。
IPS/IDSを導入する場合、以下のような運用が発生します。
- 最新のシグネチャーのアップデート
- カスタムシグネチャーの作成/削除
- 適用するシグネチャーの調整
- シグネチャーの検証
- 検査対象/検査除外するネットワークの調整
- ログ収集
- レポートの作成
- 検出後の対応
- 検出後の対応手順のメンテナンス
アンチマルウェアソフト連携管理
要件によってはアンチマルウェアソフト連携機能(Vscan)を導入することがあります。
Vscanの設定方法は以下AWS公式ブログとNetAppのテクニカルレポート、公式ドキュメントが参考になります。
Vscanを使用する場合、以下のような運用が発生します。
- アンチマルウェアソフトの定義ファイルのアップデート
- アンチマルウェアソフトのライセンス管理
- スキャン対象ファイルサイズの調整
- スキャン対象ファイルパスの調整
- スキャン対象SMBファイル共有の調整
- スキャン対象ファイル操作イベントの調整
- スキャン対象ファイル拡張子の調整
- スキャンタイムアウトの調整
- 検出後の対応
- 検出後の対応手順のメンテナンス
- アンチマルウェアソフトがインストールされたサーバーの管理
FPolicy管理
要件によっては拡張子に基づいて書き込みを制限するFPolicyを導入することがあります。
詳細は以下記事をご覧ください。
FPolicyを導入する場合、以下のような運用が発生します。
- FPolicyを適用するプロトコルの調整
- FPolicyを適用するボリューム/SMBファイル共有/エクスポートポリシーの調整
- FPolicyのファイル操作イベントの調整
- 許可/拒否する拡張子の調整
セキュリティグループのルール管理
アクセスを許可する拠点が追加/削除した場合、接続元に応じてセキュリティグループのルールを変更する必要があります。
個人情報スキャン
個人情報を扱うようなファイルサーバーでは、個人情報を適切に取り扱うことが求められます。
NIASでは個人情報が含まれるファイルをリストアップし、管理者と利用者で連携して、隔離・削除することも可能です。
このような個人情報をスキャンするようなソフトウェアに対しては以下のような運用が発生します。
- 個人情報スキャンソフトのアップデート
- 個人情報スキャンソフトのライセンス管理
- 個人情報スキャンの実施範囲の調整
- 個人情報スキャンの実施間隔の調整
- 検出された個人情報を含むファイルの取り扱い方針のメンテナンス
- 個人情報スキャンサーバーの管理
ネットワークルーティング
オンプレミスの拠点が追加になった場合など、クライアントがアクセスできるように新たにネットワーク的なルーティング設定が必要になる場合があります。
ファイルサーバーの管理者の範疇ではないかもしれないですが、オンプレミスネットワークの管理者やAWS上のネットワーク管理者と連携して設定をしましょう。
バージョンアップ
FSxNではメンテナンスウィンドウ範囲内でONTAPバージョンが自動でバージョンアップされます。
バージョンアップはユーザー側でコントロールすることはできず、事前の通知もありません。
バージョンアップが行われたのか半年に一回程度で確認しましょう。ONTAP CLIのversionコマンドで確認できます。
ONTAPのバージョンが更新されると新たな機能が使えるようになることがあります。リリースノートをチェックしておくと良いでしょう。
一方、SnapMirrorについては転送元と転送先のONTAPのバージョンが離れすぎるとサポートされません。オンプレミスONTAPとSnapMirrorしている場合は「知らない間にサポートされないSnapMirrorとなっていた」ということがないように注意しましょう。
| ONTAP version… | Interoperates with these previous ONTAP versions… | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 9.16.0 | 9.15.1 | 9.15.0* | 9.14.1 | 9.14.0* | 9.13.1 | 9.13.0* | 9.12.1 | 9.12.0* | 9.11.1 | 9.11.0* | 9.10.1 | 9.10.0* | 9.9.1 | 9.9.0* | 9.8 | 9.7 | 9.6 | 9.5 | 9.4 | 9.3 | |
| 9.16.0 | Yes | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | No | No | No | No | No | No | No | No |
| 9.15.1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No | No | No | No | No | No |
| 9.15.0* | No | Yes | Yes | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | No | No | No | No | No | No |
| 9.14.1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No | No | No | No | No |
| 9.14.0* | No | Yes | No | Yes | Yes | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | No | No | No | No | No | No |
| 9.13.1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No | No | No | No |
| 9.13.0* | No | Yes | No | Yes | No | Yes | Yes | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | No | No | No | No |
| 9.12.1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No | No | No |
| 9.12.0* | No | Yes | No | Yes | No | Yes | No | Yes | Yes | Yes | No | Yes | No | Yes | No | Yes | Yes | No | No | No | No |
| 9.11.1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No | No |
| 9.11.0* | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | Yes | Yes | No | Yes | No | Yes | Yes | Yes | No | No | No |
| 9.10.1 | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
| 9.10.0* | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | Yes | Yes | No | Yes | Yes | Yes | Yes | No | No |
| 9.9.1 | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
| 9.9.0* | No | No | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | No | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
| 9.8 | No | No | No | No | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes |
| 9.7 | No | No | No | No | No | No | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes |
| 9.6 | No | No | No | No | No | No | No | No | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes |
| 9.5 | No | No | No | No | No | No | No | No | No | No | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| 9.4 | No | No | No | No | No | No | No | No | No | No | No | No | No | No | No | No | No | No | Yes | Yes | Yes |
| 9.3 | No | No | No | No | No | No | No | No | No | No | No | No | No | No | No | Yes | Yes | Yes | Yes | Yes | Yes |
抜粋 : Compatible ONTAP versions for SnapMirror relationships
要件定義のタイミングから運用項目を整理しておこう
Amazon FSx for NetApp ONTAPをSMBファイルサーバーとして動作させる時の運用項目を整理してみました。
求められる要件によって運用項目は変動するので、要件定義のタイミングから運用項目を整理しつつ会話すると後工程がスムーズかと思います。プロジェクトが佳境になってから運用体制、運用フローを組もうとすると、場合によっては色々と考慮不足が出てくることがあり、要件や基本設計の見直しを行うことになります。
また、全社的に守るべきガイドラインやセキュリティや運用ポリシーが設けられていることもあると思います。そういったガイドラインとの関連性を意識すると良いでしょう。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
